Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-vaudreuil-smtp-binary-01.txt

Text File | 1993-10-20 | 10KB | 306 lines

     Network Working Group                         Greg Vaudreuil
     Internet Draft                             Tigon Corporation
     Expires: 4/18/94                            October 18, 1993


                            SMTP Service Extensions
                            for Binary Transmission
                             of Large MIME Messages

                      <draft-vaudreuil-smtp-binary-01.txt>

     1.Status of this Memo


     This document is an Internet Draft.  Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups.  Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are valid for a maximum of six months and may be
     updated, replaced, or obsoleted by other documents at any time.  It is
     inappropriate to use Internet Drafts as reference material or to cite
     them other than as a "work in progress".


     2.Abstract

     This memo defines an extension to the SMTP service whereby an SMTP
     client and server may negotiate the use of an alternate DATA command
     "BDAT" for sending unencoded binary MIME messages.

     3.Introduction

     The MIME extensions to the Internet message protocol provide for the
     transmission of many kinds of data which were previously unsupported
     in Internet mail.  One expected result of the use of MIME is that the
     Internet mail system will be expected to carry large binary mail
     messages, often into the megabytes.  There is a need avoid the
     overhead of base64 and quoted-printable encoding of binary objects
     sent using the MIME message format over SMTP including the requirement
     that the message be scanned for "CR LF . CR LF" sequences upon
     sending.

     This memo uses the mechanism defined in [4] to define extensions to
     the SMTP service whereby a client ("sender-SMTP") may declare support
     for the binary transmission mode and the BDAT command.

     4.Framework for the Binary Extensions

     The following service extension is hereby defined:

          1) The name of the service extension is "Binary"

          2) The EHLO keyword value associated with this extension is
          "BINARY"

          3) No parameter is used with the BINARY keyword


     Internet Draft                               Expires 4/18/94



          4) One additional parameter to the BODY keyword defined [5] for
          the MAIL FROM command is defined, "BINARYMIME".  The value
          "BINARYMIME" associated with this parameter indicates that this
          message is a Binary MIME message (in strict compliance with [3])
          with arbitrary octet content is being sent. The revised syntax of
          the value is as follows, using the ABNF notation of [2]:

               body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"

          5) A new SMTP verb is defined "BDAT" as an alternative to the
          "DATA" command of [1]

     5.The Binary service extension

     When a client SMTP wishes to submit (using the MAIL command) a content
     body consisting of a MIME message containing arbitrary octet-aligned
     material, it first issues the EHLO command to the server SMTP. If the
     server SMTP responds with code 250 to the EHLO command, and the
     response includes the EHLO keyword value BINARY, then the server SMTP
     is indicating that it supports the extended MAIL command and will
     accept MIME messages containing arbitrary octet-aligned material.

     The extended MAIL command is issued by a client SMTP when it wishes to
     transmit a content body consisting of a MIME message containing
     arbitrary octet-aligned material. The syntax for this command is
     identical to the MAIL command in [1], except that a BODY parameter
     must appear after the address.

     The complete syntax of this extended command is defined in [4]. The
     ESMTP-keyword is BODY and the syntax for ESMTP-value is given by the
     syntax for body-value shown above. A server which supports the BINARY
     transport service extension shall preserve all bits in each octet
     passed using the DATA command.

     After all MAIL FROM and RCPT TO responses are collected and processed,
     the BDAT command is sent.  The BDAT command is an alternative to the
     DATA command.  The BDAT command takes one argument, the exact length
     of the sent message in octets.  After receiving the 354 reply code,
     the message data is sent as a octet stream.  Once the receiver-SMTP
     receives the specified number of octets, it will return a 250 reply
     code.

          Note: The local storage size of a message may not accurately
          reflect the actual size of the message sent due to local storage
          conventions.  In particular, text messages sent with the BDAT
          command must be sent in the canonical CR LF terminated line
          format.

     If a server SMTP does not support the BINARY transport extension
     (either by not responding with code 250 to the EHLO command, or by not
     including the EHLO keyword value BINARY in its response), then the
     client SMTP must not, under any circumstances, send binary data using
     the DATA command.


     Vaudreuil                                           [Page 2]


     Internet Draft                               Expires 4/18/94



     If the receiver-SMTP does not support BINARY and the message content
     is a MIME object with a binary encoding, a client SMTP has two options
     in this case: first,  it may implement a gateway transformation to
     convert the message into valid 7bit encoded MIME, or second, it may
     treat this as a permanent error and handle it in the usual manner for
     delivery failures.  The specifics of the transformation from Binary
     MIME to 7bit MIME are not described by this RFC; the conversion is
     nevertheless constrained in the following ways:

          (1) it must cause no loss of information; MIME transport
          encodings must be employed as needed to insure this is the case,
          and

          (2) the resulting message must be valid 7bit MIME.

     As of present there are no mechanisms for converting a binary MIME
     object into a 8bit-MIME object.  Such a transformation will require
     the specification of a new MIME content-transfer-encoding, the
     standardization of which is discouraged.

     6.Usage Examples

     The following dialogue illustrates the use of the High Performance and
     Binary service extension to send a BINARY object to three recipients
     without the stop and wait for an explicit 250 for each recipient:

          S: <wait for connection on TCP port 25>
          C: <open connection to server>
          S: 220 cnri.reston.va.us SMTP service ready
          C: EHLO ymir.claremont.edu
          S: 250-cnri.reston.va.us says hello
          S: 250 8BITMIME
          S: 250 BINARY
          C: MAIL FROM:<[e-mail]> BINARYMIME
          S: 250 <[e-mail]>... Sender and BINARYMIME ok
          C: RCPT TO:<[e-mail]>
          S: 250 <[e-mail]>... Recipient ok
          C: RCPT TO:<[e-mail]>
          S: 250 <[e-mail]>... Recipient ok
          C: BDAT 1324
          S: 354 Send BINARYMIME message of 1324 Octets.
          ...
          S: 250 OK
          C: QUIT
          S: 250 Goodbye










     Vaudreuil                                           [Page 3]


     Internet Draft                               Expires 4/18/94



     7.Security Considerations

     This RFC does not discuss security issues and is not believed to raise
     any security issues not already endemic in electronic mail and present
     in fully conforming implementations of [1].

     8.Acknowledgments

     This document is the result of numerous discussions in the IETF SMTP
     Extensions Working Group and in particular due to the continued
     advocacy of "chunking" by Neil Katin.  Text for this document was
     liberally copied from RFC 1426 by John Klensin, Marshall Rose, Need
     Freed, Dave Crocker, and Einar Stefferud.

     9.References


          [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
          USC/Information Sciences Institute, August 1982.

          [2] Crocker, D., "Standard for the Format of ARPA Internet Text
          Messages", STD 11, RFC 822, UDEL, August 1982.

          [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
          Extensions", RFC 1341, Bellcore, Innosoft, June 1992.

          [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
          Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
          1425,

          [5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
          Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-
          MIMEtransport" RFC 1426, United Nations University, Innosoft
          International, Inc., Dover Beach Consulting, Inc., Network
          Management Associates, Inc., The Branch Office, February 1993.


     10.  Author's Address

     Gregory M. Vaudreuil
     The Tigon Corporation
     17080 Dallas Parkway
     Dallas, TX 75248-1905
     214-733-2722
     [e-mail]










     Vaudreuil                                           [Page 4]


     Internet Draft                               Expires 4/18/94


     Appendix - Changes from previous version

     o The streaming (High Performance) function was separated into a new
     capability.  This is described in a companion document
     <draft-vaudreuil-stream-00.txt>

     o Several editorial changes, including significant revision of the
     examples, were made.


     Appendix - Todo

     o SMTP senders may not be able to know the full size of the message
     before sending due to memory size limitations or a streaming data
     model.  Use of a series of BDAT commands, each with a segment of the
     message may make facilitate use of BDAT in these environments.  This
     needs to be explored.







































     Vaudreuil                                           [Page 5]